문서의 임의 삭제는 제재 대상으로, 문서를 삭제하려면 삭제 토론을 진행해야 합니다. 문서 보기문서 삭제토론 시스템 통합 (문단 편집) === 낮은 실력 === SI 산업 인력은 자사 서비스 운영을 주 수입원으로 하는 IT 기업[* 네이버, 카카오, 라인, 쿠팡, 우아한형제들(배달의민족)같은 B2C 기업들이 대표적이다. 단순히 타겟 소비자로 나뉘는 것은 아니기 때문에 B2B 기업들도 수익 모델이나 영업 형태에 따라 해당될 수 있다.]에 비해 평균적인 개발 실력이 떨어지는 편이다. 이러한 현상의 근본적인 원인은 비즈니스 모델의 차이이다. 좀 더 구체적으로 말하자면, '''소프트웨어의 품질을 고도화하는데 비용을 투입했을 때, 그것이 얼마나 회사의 이익으로 돌아오는지'''의 차이이다. SI업계에선 비싼 개발자 데려다가 소프트웨어 품질을 고도화해봐야 그다지 이득이 될 게 없다. 시스템 구축과 유지보수의 영역을 딱 잘라 나눠 계약하는데다, 연쇄하청이 일반적으로 일어나는 업계라는 점을 생각해보자. 이런 업계에선 최소한의 납품 조건만 맞춰놓고 그 다음부터는 단가 경쟁을 하는 것이 합리적인 선택이다. 이러한 SI식 비즈니스 모델에 개발자들 역시 영향을 받을 수 밖에 없다. '''(A)'''''정해진 납기와 일정 수준의 요구사항을 맞추기만 하면 그만인 경우''와, '''(B)'''''개발 사이클을 끝없이 반복하며 서비스를 고도화하고 변화하는 비즈니스 상황에 대비하여야하는 경우''를 비교해보자. 당연히 '''(B)'''가 설계 면에서나 코드 작성에서나 고려할 것이 많고 더 까다로울 수밖에 없다. 실무자들이 코드 품질에 대해서 직접적으로 대가를 치르기 때문이다. 반면, '''(A)'''와 같은 환경에선 프로젝트 끝날 때 까지만 문제 안 생기면 그만이니, 소프트웨어 개발 방법론이나 새로운 패러다임에 맞춘 기술 같은걸 공부할 필요도 없고 도입할 필요도 없다.[* 애초에 현대의 SW 개발 방법론부터가 '''(B)'''의 환경에 맞추어 탄생하고 발전해온 것이다.] 근시안적이고 유지보수에 부적합한 코드일지라도 일감을 빠르게 쳐내는 것이 좋은 개발자이기 때문이다.[* 외국의 SI업계라고 애자일이나 MSA 데브옵스 같은 최신 개발 트렌드를 적극적으로 도입하는 것은 아니지만, [[SOLID]]([[객체지향]])와 같은 소프트웨어 설계 방법론은 철저하게 준수한다는 이미지가 있다. 시스템 구축과 유지보수를 같이 계약하는 것이 일반적이기에 그렇게 하는 것이 사업적으로도 이득이기 때문이고, 그것이 기본값이 되었기 때문이다. 국내 SI에서도 객체지향은 하는거 아닌가? 싶을 수 있으나, 객체지향은 그저 상속 좀 하고 [[Spring]] 관행대로 컨트롤러와 DB접근 계층 나누는 정도에서 끝나는 개념이 아니다.][* 이런 면에서 기업 그룹 계열사들의 시스템 개발을 맡는 SI기업의 경우엔 상황이 많이 나은 편이다. 연쇄하청의 시작점이 되는 것은 어쩔수 없지만...] 그러니, 도메인 지식이니 업무 친화적 지식이니 하는 것은 부차적인 문제일 뿐이다. 무슨 개발을 하든 비즈니스 로직을 SW로 표현하고 수행하는 것이 개발자의 업무이다. 도메인 지식을 알아야하기 때문에 기술적인 역량이 부족하다는 말은 현재의 격차를 설명해주지 못한다. 그저 업계에서 그러한 역량을 필요로 하지 않기 때문에 종사자들 역시 그 쪽으로 능력을 키울 필요가 없었을 뿐이라고 봐야한다. 이러한 이유로 [[네카라쿠배]]로 대표되는 서비스 기업들은 SI 업계의 경력을 높게 쳐주지 않는 경우가 많다. SI 기업 인력들이 강점이 있는 도메인 지식은 사실 그 업무를 얼마나 오래했는가에 영향을 받기 때문에 경력이 쌓이면 차츰 늘어가는 게 있는데 기술 발전은 자기가 하지 않으면 도태되기 때문. 특히 SI 경력이 오래된 사람은 그 생활에 익숙해져서 업무 지식(=오랜 경력)이 대단한 것처럼 여기게 되는 경향이 생기는데 그건 그 업무를 안 맡게 되는 순간부터 아무런 쓸모가 없어진다. 게다가 그런 지식을 곧 밥줄이라고 여기며 지식 공유에 방어적인 태도를 보이는 분위기가 생기기까지 하니 어찌보면 당연한 것이다. 세미나, 스터디 등 사내 교육 문화에 투자하고 사원간 지식 공유를 적극 장려하는 IT 서비스 기업들과 극명하게 대비되는 부분이다. DevOps, Agile, MSA 등 최신의 트렌드를 수직적 체계의 SI에 신속하게 적용하는 것은 어렵고, 상용 개발 도구조차도 잘 안 사 주려고 한다.[* 단적인 예로, Java 개발 시 [[IntelliJ IDEA]]를 안 쓰고 무료 오픈소스 IDE인 [[이클립스(통합 개발 환경)|Eclipse]]만 고집하는 경우가 아주 많다.] 주니어-시니어가 함께 하는 코드 리뷰 문화는 그냥 다른 세계 이야기. 심지어 컴파일러 버전이 10년 가까이 된 걸 쓰는 업체도 있다. 결국 SI 업계에서 일정 수준 이상으로 발전하는 것은 한계가 있다고 봐야 한다. 그나마 Java - Spring 기술 스택이 메이저하다는 점이 점이 위안거리였지만, 그마저도 구버전과 레거시 기술 스택, SI식 방법론에 갇혀서 늘 하던대로만 개발하기 때문에 격차는 점점 벌어지고 있다.저장 버튼을 클릭하면 당신이 기여한 내용을 CC-BY-NC-SA 2.0 KR으로 배포하고,기여한 문서에 대한 하이퍼링크나 URL을 이용하여 저작자 표시를 하는 것으로 충분하다는 데 동의하는 것입니다.이 동의는 철회할 수 없습니다.캡챠저장미리보기